1. The Field of the Invention
The present invention relates to network technology; and more specifically, to mechanisms for negotiating extensions to message exchange protocols.
2. Background and Related Art
Computing technology has transformed the way we work and play. Computing systems now take a wide variety of forms including desktop computers, laptop computers, tablet PCs, Personal Digital Assistants (PDAs), household devices and the like. In its most basic form, a computing system includes system memory and one or more processors. Software in the system memory may be executed by the processor to direct the other hardware of the computing system to perform desired functions.
Networking technologies enable computing systems to communicate even over vast distances, thereby expanding on computer functionality. For example, networking technologies enable such applications as e-mail, web browsing, file transfer, instant messaging, electronic whiteboarding, network collaboration, and the like. Accordingly, computer networks enable widespread communication and information access.
Often network communication protocols define a pattern of message exchange that may be used to accomplish a particular activity. The message pattern may be as simple as a one way transmission of a single message, or may be quite complex involving numerous messages and numerous communication nodes. Regardless of complexity, such network communication protocols will be referred to herein as “message exchange protocols”.
Message exchange protocols expressly define rules regarding the types and forms of messages to be exchanged, the ordering of messages in the exchange, the role of a particular communication node in transmitting or receiving certain message types, and the like. Despite such rules, message exchange protocols often permit additional rules to be defined which are consistent with the basic message exchange protocol, but not expressly defined by the basic protocol. These additional rules may be referred to herein as “extensions” to the basic message exchange protocol.
Examples of a more complex message exchange protocol is Web Services Coordination (WS-Coordination) and Web Services Atomic Transactions (WS-AT), which use Simple Object Access Protocol (SOAP)_envelopes to exchange messages potentially even across transport-level barriers using what is often referred to as “SOAP-tunneling”. For example, a HyperText Transport Protocol (HTTP) computing system may transmit a SOAP envelope within an HTTP message to another HTTP computing system. Along the way, however, the SOAP envelope may be placed in other messages that follow different transport protocols, such as, for example, Message Queues (MQ), Simple Mail Transport Protocol (SMTP), CORBA/IIOP, or the like. Accordingly, SOAP message are considered relatively transport agnostic.
WS-Coordination describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed activities. WS-Coordination enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment.
FIG. 4A illustrates a network environment 400 in which WS-Coordination may be employed. Four computing entities are illustrated; an initiator 401, the transaction manager 402 (also referred to as TM1) associated with the initiator 401, a remote application 411, and the transaction manager 412 (also referred to as TM2) associated with the remote application 411. FIG. 4B illustrates a timeline diagram 420 showing a message exchange in accordance with a typical WS-Coordination message exchange pattern.
The initiator 401 is to initiate an activity that requires the cooperative interaction of the initiator 401, remote application 411, and their respective transaction managers 402 and 412. To do so, the initiator sends a CreateCoordinationContext message to its transaction manager TM1 as represented by arrow 421 in FIG. 4B. This message may include an endpoint reference that includes all addressing information needed for the transaction manager TM1 to properly address the requesting service at the initiator. An “endpoint reference” is defined by a Web Services protocol called WS-Addressing.
In response, the transaction manager TM1 sends a CreateCoordinationContextResponse to the initiator as represented by arrow 422. The Response 422 includes what is referred to as a Coordination Context (identified by CC1 in FIG. 4B) for transaction manager TM1. The Coordination Context CC1 includes all information needed for a computing entity to register in that activity. The response may also include an endpoint reference that includes all addressing information needed for the initiator to address the registration service at the transaction manager TM1.
The initiator 401 uses the coordination context CC1 to construct a Register request, and then sends the Register request to the transaction manager TM1 as represented by arrow 423. This Register request includes an endpoint reference to the protocol service at the initiator 401. Upon registering the initiator 401 in the activity, the transaction manager TM1 sends a RegistrationResponse to the initiator 401 as represented by the arrow 424. This response includes an endpoint reference to the protocol service at the transaction manager TM1. Thus, upon receiving the RegistrationResponse, the initiator and the transaction manager TM1 may exchange protocol level messages.
For distributed activities, the initiator may want other remote applications (such as remote application 411 in FIGS. 4A and 4B) to also register in the activity. The initiator 401 thus sends the Coordination Context CC1 for transaction manager TM1 to any such remote application 411 as represented by the arrow 425. For clarity, only one remote application 411 will be described as being involved in the activity, although WS-Coordination allows registration of multiple remote applications in the same manner as described for remote application 411.
The remote application 411 then sends a CreateCoordinationContext request to its transaction manager TM2 as represented by arrow 426. The remote application also supplies the coordination context CC1 needed to register with in the activity with the transaction manager TM1. This request may include an endpoint reference to the requesting service in the remote application.
The transaction manager TM2 responds with a CreateCoordinationContextResponse as represented by arrow 427. This response may include another CoordinationContext CC2 which includes information needed to register with the transaction manager TM2. The response may also include an endpoint reference to the registration service within the transaction manager TM2.
The remote application 411 uses the coordination context CC2 to construct a Register request, and then sends the Register request to the transaction manager TM2 as represented by arrow 428. This request may include an endpoint reference to the protocol service on the remote application 411.
Recognizing that the remote application has already provided the coordination context CC1 for the first transaction manager TM1, the second transaction manager TM2 knows to register with the first transaction manager TM1 on behalf of the remote application. The second transaction manager TM2 thus uses the coordination context CC1 to construct a Register request, and then transmits the Register request to the first transaction manager TM1 as represented by the arrow 429. This request includes an endpoint reference to the protocol service provided by the transaction manager TM2.
The first transaction manager TM1 registers the second transaction manager TM2 in the activity, and then provides a RegistrationResponse message to the second transaction manager TM2 as represented by arrow 430. The RegistrationResponse message includes an endpoint reference to the protocol service provided by the transaction manager TM1. Upon receiving this response, the transaction managers TM1 and TM2 may send post-registration protocol level messages to each other.
The second transaction manager TM2 then sends a RegistrationResponse message to the remote application as represented by arrow 431. This response includes an endpoint reference to the protocol service provided by the transaction manager TM2. Upon receiving this response, the transaction manager TM2 and the remote application 411 may exchange post-registration protocol level messages with each other.
After this interaction, three coordinator/participant relationships have been created. The relationship is defined by sending and receiving a Register request. The computing entity that sends a Register request is a “participant” in the relationship, while the computing entity that receives that Register request is a “coordinator” in the relationship. Accordingly, in one relationship, the initiator 401 is a participant, and the transaction manager TM1 is the coordinator. In a second relationship, the remote application 411 is a participant, and the transaction manager TM2 is a coordinator. In a third relationship, the transaction manager TM2 is a participant, and the transaction manager TM1 is a coordinator. It is this third relationship that involves the most complex interaction and thus will be the focus of the WS-Atomic Transaction summary, which will now be provided.
WS-Atomic Transaction is used to coordinate activities having a short duration and executed within limited trust domains. They are called atomic transactions because they have an “all or nothing” property. WS-Atomic Transaction defines, among other things, a two phase commit protocol that permits a transaction to be prepared in the first phase, followed by a commit in the second phase.
After the WS-Coordination based messaging exchange described above, the initiator 401 and the remote application 411 may engage in a number of application level message exchanges that accomplish a particular transaction. When both parties are finished the message exchange and associated processing, the initiator 401 will request of the transaction manager TM1 that the transaction be perfected. FIG. 5 illustrates a time diagram 500 showing a two-phase commit message exchange that would then occur between the two transaction managers TM1 and TM2 to complete the transaction.
The first transaction manager TM1 first sends a prepare message to the second transaction manager TM2 as represented by arrow 501. Upon receiving this message, the transaction manager TM2 does all processing needed to atomically commit the transaction upon a suitable instruction. The transaction manager TM2 then sends a prepared message to the first transaction manager TM1 as represented by arrow 502, thus completing the first phase of the two-phase commit pattern. The transaction manager TM2 then enters an in-doubt phase 505 meaning that the transaction manager TM2 does not know whether the transaction will be committed or aborted.
If the first transaction manager TM1 elects to commit the transaction, the first transaction manager TM1 then sends a commit message to the second transaction manager TM2 as represented by arrow 504. The second transaction manager TM2 then commits the transaction, and sends a committed message to the first transaction manager TM1 to thereby inform the first transaction manager TM1 that the transaction is complete.
The WS-Coordination and WS-Atomic Transaction specifications are quite powerful in that they allow for any number of distributed applications to register for and cooperatively interact to accomplish particular activities. Furthermore, the activity may be accomplished as a transaction thereby avoiding state inconsistencies between the various parties in the activities.
Although WS-Coordination and WS-Atomic Transaction are powerful, they are not perfect. While WS-Coordination and WS-Atomic Transaction are extensible, they provide no specifically expressed means for negotiating extensions to the protocols to improve upon the basic WS-Coordination and WS-Atomic Transaction protocols.
Accordingly, what would be advantageous are mechanisms for negotiating extensions to message exchange protocols, whether the message exchange protocols involve Web Services protocols such as WS-Coordination or WS-AT, or other message exchange protocols. It would further be advantageous if the basic message exchange protocol could be used as a fall back to should one or more of the parties not be aware of the negotiating mechanism since some computing entities (especially in a distributed environment) may implement the extension negotiating procedure described herein while others may not.